The need for companies to manage complex business processes has never been greater. Since the widespread use of the Internet, intranets, and extranets, the need to streamline business processes and adapt them to the emerging web architecture has become more acute. Information glut and overload has become commonplace, and it is difficult for people to “keep up.” Getting the right information to the right people at the right time (including employees, customers, and suppliers) and enabling them to act upon it in an appropriate manner is a huge and difficult undertaking.
Complex processes, the organized flow of work according to specific rules and interdependencies, are everywhere in business. They include the marketing cycle, which involves customer identification and profiling at the early stage and delivery of targeted marketing vehicles at specific time intervals during later stages. Another process with many interdependencies is the sales cycle, which typically includes multiple steps beginning with initial contact with the prospect all the way to consummating a sale. Project management, supply chain management, and customer service are a few of the other areas which involve complex chains of events that can be electronically represented, tracked and analyzed.
Managing business processes is one of the most important functions of a business. For example, sales leads are critical to revenue generation. Customer service inquiries are critical for maintaining customer satisfaction. Yet, by some estimates, 60% of leads and inquiries never get into the right person's hands (salesperson, distributor, reseller, support personnel, etc.), and this number will increase as the Internet becomes more important as a source of business. To compound the problem of lost or misdirected leads and inquiries, few companies track their business processes, including lead management, systematically as the steps in the business processes move from one party to another, to determine whether the appropriate action is taken and at what cost. As a result, companies are unable to perform return on investment (ROI) calculations on activities such as lead generation and management activities. Any product or process that can help companies manage its business processes more effectively, resulting in better sales, marketing, and customer service, will be welcome in the marketplace.
Traditional system design methods focus first on what information must be captured and stored in order to produce the needed output. The result is called the data model and much time and effort go into defining the variables (fields), their logical groupings (records) and their relative associations with other variables and groupings (relationships). The resulting definitions, referred to as a database schema, are the primary foundational architecture of any relational database application. Software products that host these data models or schemas are known as relational databases, including DB2, available from International Business Machines of White Plains, N.Y., ORACLE, available from Oracle Corporation, Redwood Shores, Calif., and MICROSOFT SQL, available from Microsoft Corporation of Redmund, Wash.
FIG. 1 is an example of a small subset of a hypothetical prior art data model representing a sales cycle. In this example, several variables or fields are logically grouped to define a contact record. For example, the field labeled “Sales status,” represents the current status of the contact named “Stewart Little” within the sales cycle. For this example, assume the sales cycle consists of the following progression of possible choices: Lead, Suspect, Prospect, Hot, Customer. Each choice represents that status of a given contact. In FIG. 1, Stewart Little is currently at the second step (i.e., “Suspect”). As an organization markets to Stewart and his status changes, the value of the Sales status field changes from Suspect to Prospect, then to Hot, then to Customer. In this data model, the value of the field determines the status of Stewart's progression within the sales process. This data model approach can be referred to as field-based process modeling.
In field-based workflow models, fields grouped together are logically associated and form “ladder”-like structures, whereby each ladder contains a description of all candidates in relation to the value being defined. An example of such a Sales Status Value ladder for the data model of FIG. 1 is shown in FIG. 2. In the example of FIG. 1, the Sales Status Value ladder of FIG. 2 shows the status of values for all candidates (Lead, Suspect, Prospect, etc). Changes to any one individual's “rung” value are captured, but the audit trail of when it changed and what it changed from is not automatically monitored or easily captured. These events must be hard coded by the application developers. Tracking changes such as the addition or deletion of fields, moreover, can be difficult to program.
Obviously, the data model of FIG. 1 is but a tiny subset of what would need to be designed into a data model capable of thoroughly representing most sales processes. Additional fields typically would be added for each data element that a sales organization might want to track in relationship to the contact. For example, the sales organization might want to capture demographic data such as age, employment, and income information etc. Different campaigns or marketing processes could feed off of these variables.
Access to data models such as that shown in FIG. 1 historically have been facilitated via application languages like COBOL and Fortran (used in the 70's and 80's) Powerbuilder, FoxPro, Visual Basic, C++ (Popular in the 90s), and currently popular techniques such as Active Server Pages (ASP), Extensible Markup Language (XML), Hypertext Markup Language (HTML) and other web-based languages. Essentially, these application languages provide the developer with the toolkit for defining the way and manner in which the user interacts with the data model—the user interface.